Software development is typically performed as group projects. A subject software system is developed through design efforts, test efforts, implementation efforts and maintenance efforts. There may be different groups and different group members participating in each of these efforts. Throughout these efforts and among the work group members, various modeling and other development tools are used for increased communication and consistency in developing the subject software system. A software configuration management system is one such tool. Software configuration management systems allow teams of users (software developer/engineer) to work with artifacts of a subject software system.
A software artifact is a persistent representation of an aspect of a software system. Common examples of software artifacts are files and directories containing the source code of a software system, but other examples of artifacts include requirements, end-user documentation, system models, and system tests. A significant state of a software artifact is saved as a version of that artifact, and the sets of versions of a given artifact define the history of that artifact.
A software configuration is a set of software artifact versions, where only one version of a given artifact is selected by a given software configuration. A software change-set identifies a logical change to a configuration, and consists of a set of one or more changes to one or more artifacts. An alternative characterization of a software configuration is that it consists of the set of change-sets that have resulted in that configuration.
When a team of software developers is creating and modifying files to create new configurations of a software system, each developer needs to have a private copy of the files so that he can test his changes without being disrupted by changes being made by the other developers. The object that maintains a private copy for a particular developer is called a workspace, and the files for a workspace are stored in a file system tree that is called the file area of the workspace. The file area contains both shared files (that are shared with the other members of the team) and private files (that are available only in that file area). To support disconnected use, the file area is stored on the local disk on the developer's machine. When a developer is ready to make his changes available to other team members, he checks in any shared files and folders he has changed in his file area, which creates an immutable version of those files and folders in a team repository.
It is often important for a developer to be able to inspect the state of the files in another developer's workspace. The most current state of a file is in the file area of that workspace (for example, the current state of files being modified is usually only available in the file area), but the file area of a developer's workspace is commonly inaccessible to most other developers (especially if the owner of the workspace is working disconnected). A good approximation of the state of the files in a workspace usually can be obtained from the checked-in state of those files, and that state is available to any developer that has access to the team repository. This means that there are two different naming trees that can be used to obtain the state of files in a workspace: the file area naming tree (file pathnames) and the repository naming tree (repository pathnames). The file referencing mechanism must allow a developer to specify which namespace they want to use (since the actual states of files in these two namespaces can differ), but to avoid unnecessary complexity, the mechanisms for accessing files in these two namespaces should be as uniform as possible. In particular, it should be feasible for the system to automatically transform a file area reference into a repository reference, and vice versa. In particular, if a developer has a reference to a file in the file naming tree of another developer, the system should be able to automatically convert that reference into a reference to the checked-in state of that file in the repository, so that it can give the developer the option of browsing the checked-in state instead. Conversely, if a developer has a reference to a file in the repository, and that file area for that file is on the developer's machine, the system should be able to automatically convert that repository reference into a reference to the corresponding file in the file area, even if the developer is currently disconnected from the repository.
When a developer uses a reference, it is important for the system to be able to detect whether the state of the file being referenced has changed since the reference was created.
One complication that can arise is that a file in the file area may have been renamed or moved in the file area, but the modified folders that capture the new location of that file have not yet been checked in to the repository.